A common requirement for database systems is the ability to provide a snapshot (i.e., a copy) of the database at a specified point in time. In particular, the “consistent read” capability of many databases requires providing the ability to run a query against the committed state of specific data (e.g., a database) at a specified point in time. A common case is at the time corresponding to the start of this query processing. Other times are possible and generally need to be supported. For example, a query may select the gold customers with more than 1 million dollars in orders as of close of business yesterday. Additional requirements include the abilities to recover the committed state of the database on a failure, and to provide time series data about a dataset (i.e. its changes in value over time).
Typically, consistent read and recovery functions are implemented in software. Existing implementations often result in memory-intensive operations that negatively impact the performance of the processor caches because these operations bring extra data (e.g., log data and/or metadata) into the processor caches. In particular, the processing is often stalled waiting for the data from the main memory, and other data that is relevant to the on-going processing may be evicted from the processor cache to provide space for the extra data.
Moreover, under increased load, it is common for a transaction to require a consistent read of a block of data that has been modified since the start of the query, thus incurring the cost of rolling back the current state to the time the query was started. These costs tend to increase with increasing load on the system, leading to non-graceful degradation.
The typical software implementation of consistent read and recovery functions further suffers from synchronization overhead with other processor cores running on the same system, as it is necessary to access the data structures of the log and buffer pool concurrently with other processor cores in the system. This synchronization is effectively additional inter-core cache traffic, further reducing the performance of each core as well as the overall system performance.
The typical software implementation of consistent read and recovery functions relies on undo and redo logs. The same issue mentioned above arises with a software implementation of writing to undo and redo logs on database update because the processor core needs to access metadata and data and synchronization frequently. In particular, to add an undo record to the undo log and a redo record to the redo log as part of recording an update in a transaction, the processor needs to access the data corresponding to the end of undo log as well as data corresponding to the end of the redo log, and then perform writes to both. The updating process must also access any ancillary/management data structures associated with these logs as well as the code segments storing the instructions for performing these actions. It also needs to synchronize with other processor cores to perform updates on these logs. Performance is therefore negatively impacted.